<html>
<head><meta charset="utf-8"><title>LLVM capabilities vs cranelift · t-lang · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/index.html">t-lang</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html">LLVM capabilities vs cranelift</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="190442304"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190442304" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nikomatsakis <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190442304">(Mar 12 2020 at 20:40)</a>:</h4>
<p>So, in the meeting today, the question of whether it's ok for some features to not be supported by all backends came up. In particular, we were talking about the proposed <code>#[instruction_set]</code> attribute, which may be easy to support in LLVM (I don't know that for a fact, I'm assuming) but would probably be more work for (say) cranelift. I said that to my mind it'd be ok if a hypothetical cranelift backend gave an error on code that used it, but <span class="user-mention" data-user-id="126931">@centril</span> disagreed. I thought it might be worth talking that out in more detail, because I foresee this being a topic that comes up again, especially as we talk about supporting more low-level features. It certainly arose for inline assembly, for example.</p>



<a name="190442377"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190442377" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nikomatsakis <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190442377">(Mar 12 2020 at 20:41)</a>:</h4>
<p>I feel like my <em>preferred</em> outcome is that  <code>#[instruction_set]</code> is considered a hint, and that it works uniformly across all backends (perhaps with a warning on cranelift or something if it's unsupported).</p>



<a name="190442482"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190442482" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nikomatsakis <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190442482">(Mar 12 2020 at 20:42)</a>:</h4>
<p>An interesting question is whether it'd be ok to have inline assembly be unsupported in a similar way. I might be ok with that, but I also feel somewhat differently about inline asm vs instruction-set, I guess because the latter seems rather more niche, whereas it seems quite possible that you'll pull down some random crate from <a href="http://crates.io" target="_blank" title="http://crates.io">crates.io</a> that requires inline assembly.</p>



<a name="190442497"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190442497" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> pnkfelix <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190442497">(Mar 12 2020 at 20:42)</a>:</h4>
<p>context: <a href="https://github.com/rust-lang/rfcs/pull/2867" target="_blank" title="https://github.com/rust-lang/rfcs/pull/2867">https://github.com/rust-lang/rfcs/pull/2867</a></p>



<a name="190442540"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190442540" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nikomatsakis <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190442540">(Mar 12 2020 at 20:43)</a>:</h4>
<p>Overall I guess I am worried about some kind of rule that says "everything must be easily supported by any 'ordinary' backend" -- it seems like it will limit us from taking full advantage of LLVM.</p>



<a name="190442617"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190442617" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> pnkfelix <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190442617">(Mar 12 2020 at 20:43)</a>:</h4>
<p>(and it might also be in conflict with our goal of "parity with C" ... depending on what that means ...)</p>



<a name="190442662"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190442662" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nikomatsakis <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190442662">(Mar 12 2020 at 20:44)</a>:</h4>
<p>(At the same time, I don't want us to be permanently wedded to LLVM, so there's some kind of line there...)</p>



<a name="190442666"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190442666" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nikomatsakis <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190442666">(Mar 12 2020 at 20:44)</a>:</h4>
<p><span class="user-mention silent" data-user-id="116083">pnkfelix</span> <a href="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190442617" title="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190442617">said</a>:</p>
<blockquote>
<p>(and it might also be in conflict with our goal of "parity with C" ... depending on what that means ...)</p>
</blockquote>
<p>right</p>



<a name="190442757"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190442757" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190442757">(Mar 12 2020 at 20:45)</a>:</h4>
<p>I personally think we should try to avoid tying to LLVM specifics, but we should also be open to "not all backends do this" -- e.g., <code>#[inline]</code> though entirely a hint is kinda like this -- not all backends would inline anything of course</p>



<a name="190442810"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190442810" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nikomatsakis <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190442810">(Mar 12 2020 at 20:45)</a>:</h4>
<p>Yes, this kind of optimization hint is sort of the "easy case"</p>



<a name="190442926"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190442926" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nikomatsakis <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190442926">(Mar 12 2020 at 20:46)</a>:</h4>
<p>But there's a difference between "tying to LLVM specifics" and "taking advantage of what LLVM offers"</p>



<a name="190442937"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190442937" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nikomatsakis <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190442937">(Mar 12 2020 at 20:46)</a>:</h4>
<p>Naked functions are another potential example</p>



<a name="190443012"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190443012" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190443012">(Mar 12 2020 at 20:47)</a>:</h4>
<p>My line would personally be that things might be a warning, but we should try to avoid cases where it's a hard error if you swap backends on the common case</p>



<a name="190443014"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190443014" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nikomatsakis <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190443014">(Mar 12 2020 at 20:47)</a>:</h4>
<p>(From what I understand, this is a common feature in many C compilers, but maybe not supported by cranelift. Not to get into whether we want it specifically or not, of course.)</p>



<a name="190443060"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190443060" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> pnkfelix <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190443060">(Mar 12 2020 at 20:47)</a>:</h4>
<p>I continue to be concerned about ABI impact.</p>



<a name="190443061"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190443061" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190443061">(Mar 12 2020 at 20:47)</a>:</h4>
<p>(but e.g. for the ARM instruction_set stuff, it seems like people in that world are used to and would be quite fine with "well I need to use LLVM as a backend")</p>



<a name="190443126"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190443126" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Amanieu <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190443126">(Mar 12 2020 at 20:48)</a>:</h4>
<p>Regarding <code>#[instruction_set]</code>, it should be an error if it is not supported by the backend. There are visible effects, e.g. if that function uses inline asm, or if it uses floats (not supported on Thumb, gets lowered to a compiler-rt call).</p>



<a name="190443165"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190443165" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> pnkfelix <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190443165">(Mar 12 2020 at 20:48)</a>:</h4>
<p>From Lokathor's summary:</p>
<blockquote>
<p>The linkers for ARM targets can adjust function calls so that calls from ARM to Thumb and back can use bx and blx as appropriate (eg: GNU ld calls the flag -mthumb-interwork), again based on the address of the jump target.</p>
</blockquote>



<a name="190443240"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190443240" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> pnkfelix <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190443240">(Mar 12 2020 at 20:48)</a>:</h4>
<p>The fact that you have to invoke GNU <code>ld</code>  with a special flag to make this work adds to my concern.</p>



<a name="190443266"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190443266" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> centril <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190443266">(Mar 12 2020 at 20:49)</a>:</h4>
<p>Taking advantage of LLVM in hints is quite different than adding new requirements &amp; behaviors in the language spec</p>



<a name="190443278"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190443278" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> centril <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190443278">(Mar 12 2020 at 20:49)</a>:</h4>
<p>Hints can be entirely ignored in the spec</p>



<a name="190443306"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190443306" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> centril <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190443306">(Mar 12 2020 at 20:49)</a>:</h4>
<p>Lints are similarly not part of the spec</p>



<a name="190443317"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190443317" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> pnkfelix <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190443317">(Mar 12 2020 at 20:49)</a>:</h4>
<p><span class="user-mention silent" data-user-id="116083">pnkfelix</span> <a href="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190443240" title="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190443240">said</a>:</p>
<blockquote>
<p>The fact that you have to invoke GNU <code>ld</code>  with a special flag to make this work adds to my concern.</p>
</blockquote>
<p>(but maybe that flag is not that special? I'm often confused my the <code>-mfamily</code> of flags in gcc)</p>



<a name="190443399"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190443399" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nikomatsakis <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190443399">(Mar 12 2020 at 20:50)</a>:</h4>
<p><span class="user-mention silent" data-user-id="116122">simulacrum</span> <a href="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190443012" title="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190443012">said</a>:</p>
<blockquote>
<p>My line would personally be that things might be a warning, but we should try to avoid cases where it's a hard error if you swap backends on the common case</p>
</blockquote>
<p>this is kind of where I fall. For a feature that we expect to be "commonly found" in crates, I would want it to not rely on highly specialized features (though I think there is a choice here; it seems ok to me for us to make demands of our backends too). But I expect some things to be more narrowly used and for that I don't necessarily feel all targets/backends must support it.</p>



<a name="190443470"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190443470" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> centril <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190443470">(Mar 12 2020 at 20:51)</a>:</h4>
<p>Making demands on our backend might not be successful, depending on "our power" and the backend</p>



<a name="190443486"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190443486" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190443486">(Mar 12 2020 at 20:51)</a>:</h4>
<p>Maybe there's also some middle ground here -- e.g., I would hope that maybe we can find a way to have "backend-specific" details that are still RFCd and such. I think having that is pretty key in some way. Having to tie everything to a lowest common denominator feels pretty bad</p>



<a name="190443493"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190443493" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> centril <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190443493">(Mar 12 2020 at 20:51)</a>:</h4>
<p>e.g. cranelift might be amenable to make changes for us</p>



<a name="190443645"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190443645" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> centril <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190443645">(Mar 12 2020 at 20:52)</a>:</h4>
<p>I don't think it's bad personally; I don't think we should be making too many demands on a backend, to the point that making one becomes unreasonably hard, and it might also create problems for future backends.</p>



<a name="190443656"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190443656" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> pnkfelix <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190443656">(Mar 12 2020 at 20:52)</a>:</h4>
<p><span class="user-mention silent" data-user-id="116083">pnkfelix</span> <a href="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190443060" title="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190443060">said</a>:</p>
<blockquote>
<p>I continue to be concerned about ABI impact.</p>
</blockquote>
<p>also from Lokathor's summary:</p>
<blockquote>
<ul>
<li><em>Is this an alternate ABI, like C-unwind and C-nounwind? / Does this need to show up in the type system?</em></li>
</ul>
<p>Nope. LLVM, the linker, and the CPU all carry around the correct info about functions and function pointers based on the lowest bit of the address.  [...] The inter-procedure call format also doesn't change <a href="https://github.com/rust-lang/rfcs/pull/2867#issuecomment-588016707" target="_blank" title="https://github.com/rust-lang/rfcs/pull/2867#issuecomment-588016707">[...]</a></p>
</blockquote>



<a name="190443871"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190443871" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> centril <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190443871">(Mar 12 2020 at 20:54)</a>:</h4>
<p>As for LLVM specifically, I am wary of our dependence on it... I am wary of being at the mercy of C++ and LLVM's priorities (esp. wrt. soundness, compile times).<br>
If features that a lot of users use can only be used on LLVM, then it means that any alternative backend is a second class citizen, and won't really be used.</p>



<a name="190443996"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190443996" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> centril <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190443996">(Mar 12 2020 at 20:55)</a>:</h4>
<p><span class="user-mention silent" data-user-id="116009">nikomatsakis</span> <a href="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190442377" title="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190442377">said</a>:</p>
<blockquote>
<p>I feel like my <em>preferred</em> outcome is that  <code>#[instruction_set]</code> is considered a hint, and that it works uniformly across all backends (perhaps with a warning on cranelift or something if it's unsupported).</p>
</blockquote>
<p>I think that means we don't have any spec dependence on LLVM here, and that would be good. If that's the outcome we can tuck it under <code>#[optimize(...)]</code>, simplifying the spec in the process.</p>



<a name="190444187"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190444187" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190444187">(Mar 12 2020 at 20:57)</a>:</h4>
<p>Also, am I wrong, or is instruction_set not actually spec dependence on LLVM? i.e. the details on what it means are entirely "open" and not tied to LLVM specific details?</p>



<a name="190444202"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190444202" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> pnkfelix <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190444202">(Mar 12 2020 at 20:57)</a>:</h4>
<p>If we are putting any particular weight on Lokathor's expertise here, they also said this:</p>
<blockquote>
<ul>
<li><em>Is this an optimization hint?</em><br>
No, to be useful it must be an absolute guarantee that tagged functions are generated using the correct code format. It affects the inline assembly that you write, and it even affects the code's ability to be used at all in select situations.</li>
</ul>
</blockquote>



<a name="190444333"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190444333" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> pnkfelix <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190444333">(Mar 12 2020 at 20:58)</a>:</h4>
<p>My reading is that this is not LLVM specific at all, at least not in this context. Or at least, if GNU ld supports it, then I infer its not an LLVM specific thing.</p>



<a name="190444341"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190444341" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> centril <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190444341">(Mar 12 2020 at 20:58)</a>:</h4>
<p><span class="user-mention silent" data-user-id="116122">simulacrum</span> <a href="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190444187" title="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190444187">said</a>:</p>
<blockquote>
<p>Also, am I wrong, or is instruction_set not actually spec dependence on LLVM? i.e. the details on what it means are entirely "open" and not tied to LLVM specific details?</p>
</blockquote>
<p>Well if it is not a hint, then it compells other backends to expose a way to also achieve the behavior (unless it's an error on those backends)</p>



<a name="190444380"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190444380" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> pnkfelix <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190444380">(Mar 12 2020 at 20:59)</a>:</h4>
<p>(And it is rather an ARM architecture thing. Maybe MIPS as well; need to double check the conversation there.)</p>



<a name="190444464"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190444464" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> pnkfelix <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190444464">(Mar 12 2020 at 20:59)</a>:</h4>
<p>The whole magic dispatch based on the low order bit sounds <em>very</em> target specific</p>



<a name="190444466"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190444466" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190444466">(Mar 12 2020 at 20:59)</a>:</h4>
<p>My point is that I can understand being against LLVM-specific details finding their way into our spec -- but I'm  pretty fine with saying "we accept this feature, with the implication that yes, any backend that wants to be a Rust backend, will need to support it"</p>



<a name="190444503"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190444503" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> centril <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190444503">(Mar 12 2020 at 20:59)</a>:</h4>
<p><span class="user-mention silent" data-user-id="116083">pnkfelix</span> <a href="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190442617" title="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190442617">said</a>:</p>
<blockquote>
<p>(and it might also be in conflict with our goal of "parity with C" ... depending on what that means ...)</p>
</blockquote>
<p>This sorta makes me wary of "party with C" as a goal. At least in the way I think it is being used ("parity with various non-standard GCC extensions"); and I think that comes with a huge amount of ad-hoc complexity to the language.</p>



<a name="190444559"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190444559" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190444559">(Mar 12 2020 at 21:00)</a>:</h4>
<p>Is that your stance as well <span class="user-mention" data-user-id="126931">@centril</span> ?</p>



<a name="190444666"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190444666" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> centril <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190444666">(Mar 12 2020 at 21:01)</a>:</h4>
<p><span class="user-mention" data-user-id="116122">@simulacrum</span> depends; you can phrase things LLVM supports in such a way that the backend must look very LLVM-ish</p>



<a name="190444694"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190444694" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> centril <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190444694">(Mar 12 2020 at 21:01)</a>:</h4>
<p>and making too many requirements on a backend can also be a problem</p>



<a name="190444713"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190444713" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> centril <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190444713">(Mar 12 2020 at 21:01)</a>:</h4>
<p>but highly LLVM-specific things would be worse</p>



<a name="190444809"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190444809" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190444809">(Mar 12 2020 at 21:02)</a>:</h4>
<p>...Yes? But you agree that we can have things that <em>today</em> are implemented only in LLVM (and not, for example, cranelift), without even necessarily the cranelift developers saying "we will do this"</p>



<a name="190444858"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190444858" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190444858">(Mar 12 2020 at 21:02)</a>:</h4>
<p>or do you feel that we need to okay features affecting codegen with cranelft development?</p>



<a name="190444861"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190444861" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> centril <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190444861">(Mar 12 2020 at 21:02)</a>:</h4>
<p>Not in general, I don't agree.</p>



<a name="190444913"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190444913" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> centril <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190444913">(Mar 12 2020 at 21:03)</a>:</h4>
<p>It depends on the feature, but I think cranelift should be consulted</p>



<a name="190444933"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190444933" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190444933">(Mar 12 2020 at 21:03)</a>:</h4>
<p>I don't mean in general. I mean features that are not LLVM specific (e.g., instruction set, I imagine there's dozens of others), but do need backend support.</p>



<a name="190445035"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190445035" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> centril <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190445035">(Mar 12 2020 at 21:04)</a>:</h4>
<p><span class="user-mention" data-user-id="116122">@simulacrum</span> that would be e.g. a backend feature that both gcc and llvm support, for example?</p>



<a name="190445056"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190445056" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190445056">(Mar 12 2020 at 21:04)</a>:</h4>
<p>For example, sure.</p>



<a name="190445061"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190445061" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> centril <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190445061">(Mar 12 2020 at 21:04)</a>:</h4>
<p>Same answer then</p>



<a name="190445123"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190445123" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> centril <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190445123">(Mar 12 2020 at 21:04)</a>:</h4>
<p>In practical terms it means relying on LLVM specifics, as we don't have another backend</p>



<a name="190445140"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190445140" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190445140">(Mar 12 2020 at 21:04)</a>:</h4>
<p>(e.g., something supported across MSVC/GCC/LLVM, but not yet in cranelift, with a solid spec not tied to the internals of those impls)</p>



<a name="190445163"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190445163" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190445163">(Mar 12 2020 at 21:05)</a>:</h4>
<p>imo, I think we should accept features that have that reach and not block on cranelft agreeing to it</p>



<a name="190445188"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190445188" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190445188">(Mar 12 2020 at 21:05)</a>:</h4>
<p>(modulo us wanting that feature, of course)</p>



<a name="190445272"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190445272" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> centril <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190445272">(Mar 12 2020 at 21:06)</a>:</h4>
<p>I think this is starting to get rather hypothetical and feature specific so I don't want to answer the question in its generality</p>



<a name="190445349"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190445349" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190445349">(Mar 12 2020 at 21:06)</a>:</h4>
<p>I mean, I definitely don't expect to quote you later and say "but you felt this way" -- I'm just trying to get a read of your position on this</p>



<a name="190445414"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190445414" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190445414">(Mar 12 2020 at 21:07)</a>:</h4>
<p>(and maybe your position is that you don't want to make any general statement at all because you feel that each feature is sufficiently unique. I disagree, but that's fine :)</p>



<a name="190445455"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190445455" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> centril <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190445455">(Mar 12 2020 at 21:08)</a>:</h4>
<p>hehe <span aria-label="slight smile" class="emoji emoji-1f642" role="img" title="slight smile">:slight_smile:</span><br>
Well, depending on how solid the spec is and how much it ties us to things looking like LLVM, etc. I might feel differently.<br>
At any rate, I think at minimum, talking to the cranelift people is at least a courteous and polite thing to do.</p>



<a name="190445531"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190445531" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> centril <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190445531">(Mar 12 2020 at 21:08)</a>:</h4>
<p>We shouldn't be surprising them with stuff</p>



<a name="190445545"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190445545" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190445545">(Mar 12 2020 at 21:08)</a>:</h4>
<p>Certainly I think it would be helpful to have a read on whether a backend like cranelift <em>could</em> implement it -- that helps provide us context on how well written the spec is and how truly "cross backend" it is</p>



<a name="190445561"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190445561" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> centril <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190445561">(Mar 12 2020 at 21:09)</a>:</h4>
<p>Yep</p>



<a name="190445596"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190445596" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190445596">(Mar 12 2020 at 21:09)</a>:</h4>
<p>but I would be against blocking instruction_set or other features on an implementation in cranelift existing</p>



<a name="190445616"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190445616" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> pnkfelix <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190445616">(Mar 12 2020 at 21:09)</a>:</h4>
<p>Thinking more about Lokathor's comment regarding whether this "cannot' be a hint.. I wonder if we would be best served with two attributes: One that is a best-effort hint, and another that causes a compile-time failure if the backend doesn't support the requested setting.</p>



<a name="190445705"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190445705" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190445705">(Mar 12 2020 at 21:10)</a>:</h4>
<p><span class="user-mention" data-user-id="116083">@pnkfelix</span> my impression was that most use cases for this really can't be a hint <em>because</em> the thing you're doing inside the function is dependent on that instruction set (e.g., inline assembly)</p>



<a name="190445719"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190445719" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> pnkfelix <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190445719">(Mar 12 2020 at 21:10)</a>:</h4>
<p>(at least, it seems like the discussion so far implies that we would need to choose between those two options. But maybe that choice is better left to the fn-implementer, depending on whether the request is indeed a mere optimization vs  inline assembly.)</p>



<a name="190445737"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190445737" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> pnkfelix <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190445737">(Mar 12 2020 at 21:11)</a>:</h4>
<p>Right, I understand that there are plenty of cases where it really does need to hard error</p>



<a name="190445853"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190445853" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> centril <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190445853">(Mar 12 2020 at 21:12)</a>:</h4>
<p>(Well my inference re. interactions with inline asm is that this is an argument against inline asm... but let's not dive into that here)</p>



<a name="190445868"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190445868" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> pnkfelix <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190445868">(Mar 12 2020 at 21:12)</a>:</h4>
<p>but when we talk about categorizing this under the umbrella of <code>optimize</code>, then that to me falls more into the category of "best effort attempt to use the more compact instruction set"</p>



<a name="190445921"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190445921" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> centril <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190445921">(Mar 12 2020 at 21:13)</a>:</h4>
<p><span class="user-mention" data-user-id="116083">@pnkfelix</span> right, that feels like <span class="user-mention" data-user-id="116009">@nikomatsakis</span>'s preferred outcome</p>



<a name="190446023"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190446023" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> centril <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190446023">(Mar 12 2020 at 21:14)</a>:</h4>
<p><span class="user-mention silent" data-user-id="116122">simulacrum</span> <a href="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190445596" title="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190445596">said</a>:</p>
<blockquote>
<p>but I would be against blocking instruction_set or other features on an implementation in cranelift existing</p>
</blockquote>
<p>I think we have a difference of opinion here. <span aria-label="slight smile" class="emoji emoji-1f642" role="img" title="slight smile">:slight_smile:</span></p>



<a name="190446036"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190446036" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190446036">(Mar 12 2020 at 21:14)</a>:</h4>
<p>I agree :)</p>



<a name="190446116"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190446116" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190446116">(Mar 12 2020 at 21:15)</a>:</h4>
<p>I wonder if the middle ground is a optimize-like attribute, and then a intrinsic (stabilized, I guess) which says "you're in this instruction mode" -- the idea being that if you really need it you can do <code>if !is_small() { panic!("..."); }</code> or something like that</p>



<a name="190446138"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190446138" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> centril <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190446138">(Mar 12 2020 at 21:15)</a>:</h4>
<p>Anyways... Dinner awaits, so I bid y'all adieu for now <span aria-label="egg" class="emoji emoji-1f95a" role="img" title="egg">:egg:</span> <span aria-label="bread" class="emoji emoji-1f35e" role="img" title="bread">:bread:</span></p>



<a name="190446186"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190446186" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190446186">(Mar 12 2020 at 21:15)</a>:</h4>
<p>that at least sort of forces people to handle it at runtime</p>



<a name="190446248"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190446248" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190446248">(Mar 12 2020 at 21:16)</a>:</h4>
<p>(though arguably that's perhaps worse than a compile time error, so I'm not sure)</p>



<a name="190446259"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190446259" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nikomatsakis <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190446259">(Mar 12 2020 at 21:16)</a>:</h4>
<p>Thinking about backends a bit more</p>



<a name="190446272"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190446272" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nikomatsakis <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190446272">(Mar 12 2020 at 21:16)</a>:</h4>
<p>It seems obvious that cranelift won't be able to support all targets</p>



<a name="190446302"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190446302" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nikomatsakis <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190446302">(Mar 12 2020 at 21:16)</a>:</h4>
<p><span class="user-mention silent" data-user-id="126931">centril</span> <a href="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190443871" title="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190443871">said</a>:</p>
<blockquote>
<p>As for LLVM specifically, I am wary of our dependence on it... I am wary of being at the mercy of C++ and LLVM's priorities (esp. wrt. soundness, compile times).<br>
If features that a lot of users use can only be used on LLVM, then it means that any alternative backend is a second class citizen, and won't really be used.</p>
</blockquote>
<p>I found this comment helpful to understand better where <span class="user-mention" data-user-id="126931">@centril</span> is coming from</p>



<a name="190446359"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190446359" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nikomatsakis <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190446359">(Mar 12 2020 at 21:17)</a>:</h4>
<p>I guess what I was most hoping to get out of this conversation was not an "answer"</p>



<a name="190446362"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190446362" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190446362">(Mar 12 2020 at 21:17)</a>:</h4>
<p>Yes, I found this helpful as well -- and indeed agree with it.</p>



<a name="190446382"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190446382" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nikomatsakis <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190446382">(Mar 12 2020 at 21:17)</a>:</h4>
<p>but a better feeling for what the "concerns" are and factors we might consider</p>



<a name="190446477"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190446477" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nikomatsakis <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190446477">(Mar 12 2020 at 21:18)</a>:</h4>
<p>It does seem good to me to ponder "how hard is it for backends like cranelift to support this", for example.</p>



<a name="190446562"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190446562" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nikomatsakis <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190446562">(Mar 12 2020 at 21:19)</a>:</h4>
<p>That said, i'm not sure I agree with the premise that cranelift would be a "second class citizen" if it can't support features like <code>#[instruction_set]</code>. I think that is one outcome, but I could also imagine pushback on using those features if the cranelift backend is sufficiently better (e.g. faster). I could also imagine someone just extending cranelift with that feature :)</p>



<a name="190446688"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190446688" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nikomatsakis <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190446688">(Mar 12 2020 at 21:20)</a>:</h4>
<p>probably the bigger concern is stuff like debuginfo etc</p>



<a name="190446716"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190446716" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nikomatsakis <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190446716">(Mar 12 2020 at 21:20)</a>:</h4>
<p>but that's clearly table stakes :)</p>



<a name="190446725"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190446725" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190446725">(Mar 12 2020 at 21:20)</a>:</h4>
<p>I think this is why my opinion settles mostly on it being <em>possible</em> if hard to implement -- where possible to me essentially means "you can go read some website/PDF/or something" and not "you have to read LLVM's impl" basically</p>



<a name="190446812"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190446812" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190446812">(Mar 12 2020 at 21:21)</a>:</h4>
<p>e.g. for debuginfo there's a DWARF standard, and while someone implementing may look for reference at what is done "in practice" it's not actually required that they do so</p>



<a name="190452642"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190452642" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190452642">(Mar 12 2020 at 22:28)</a>:</h4>
<p>Hello all.</p>



<a name="190452870"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190452870" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190452870">(Mar 12 2020 at 22:31)</a>:</h4>
<p>So let me see if i can help clear up some stuff.</p>
<p>for Cranelift to support this and the initial a32/t32 support it would need:<br>
, the ability to generate a32 code, which is already necessary to support arm target triples<br>
, the ability to generate t32 code, which is already necessary to support thumb target triples<br>
, knowing to call the linker with the extra flag</p>



<a name="190452971"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190452971" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190452971">(Mar 12 2020 at 22:33)</a>:</h4>
<p>That is it really</p>



<a name="190453088"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190453088" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190453088">(Mar 12 2020 at 22:34)</a>:</h4>
<p>Currently Cranelift supports nothing at all in the ARM family, but if it adds support for those two codegen types then the instruction_set attribute essentially just falls out of it as a consequence</p>



<a name="190454981"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190454981" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190454981">(Mar 12 2020 at 23:03)</a>:</h4>
<p>Also, I would like to stress again that this is not a hint. Some hardware will have function pointers you can assign via MMIO and then the firmware will jump to that function and the function must be in the correct code format or it's UB.</p>



<a name="190455078"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190455078" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190455078">(Mar 12 2020 at 23:04)</a>:</h4>
<p>So, in the same way that you probably wouldn't accept if a wasm backend just gave up some of the time and insterted x86_64 code instead, it would be unacceptable to have the wrong codegen with this attribute.</p>



<a name="190455108"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190455108" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190455108">(Mar 12 2020 at 23:05)</a>:</h4>
<p>It's perfectly fine for the backend to just error and say it can't support the requested operation of course.</p>



<a name="190455123"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190455123" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190455123">(Mar 12 2020 at 23:05)</a>:</h4>
<p>but it can't silently decode to do something else</p>



<a name="190455521"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190455521" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190455521">(Mar 12 2020 at 23:10)</a>:</h4>
<p>(Note: I was on a plane when the original discussion took place, hence my sequentially going through and replying to things.)</p>
<p><span class="user-mention silent" data-user-id="116009">nikomatsakis</span> <a href="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190442377" title="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190442377">said</a>:</p>
<blockquote>
<p>I feel like my <em>preferred</em> outcome is that  <code>#[instruction_set]</code> is considered a hint, and that it works uniformly across all backends (perhaps with a warning on cranelift or something if it's unsupported).</p>
</blockquote>
<p>instruction_set is not a hint, it's potentially required for correctness, for multiple reasons. Cranelift is going to need to support Thumb at some point. In the meantime, I think it's perfectly reasonable for it to emit an error stating that it isn't supported.</p>



<a name="190455569"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190455569" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190455569">(Mar 12 2020 at 23:11)</a>:</h4>
<p><span class="user-mention silent" data-user-id="116009">nikomatsakis</span> <a href="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190442540" title="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190442540">said</a>:</p>
<blockquote>
<p>Overall I guess I am worried about some kind of rule that says "everything must be easily supported by any 'ordinary' backend" -- it seems like it will limit us from taking full advantage of LLVM.</p>
</blockquote>
<p>Agreed completely. We are not a magical portability layer that must abstract over every possible difference between targets, and we certainly shouldn't force a lowest common denominator. We should take full advantage of a target when doing so provides value.</p>



<a name="190455909"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190455909" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190455909">(Mar 12 2020 at 23:17)</a>:</h4>
<p><span class="user-mention silent" data-user-id="126931">centril</span> <a href="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190443645" title="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190443645">said</a>:</p>
<blockquote>
<p>I don't think it's bad personally; I don't think we should be making too many demands on a backend, to the point that making one becomes unreasonably hard, and it might also create problems for future backends.</p>
</blockquote>
<p>I feel precisely the opposite: we should hopefully, one day, be the force pushing our backends forward faster than C does, and providing access to interesting new functionality. At the very least, we should not be refusing to support existing functionality that our users need because of another backend that doesn't support it, let alone for a backend that we don't have yet.</p>



<a name="190456023"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190456023" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190456023">(Mar 12 2020 at 23:18)</a>:</h4>
<p><span class="user-mention silent" data-user-id="126931">centril</span> <a href="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190443871" title="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190443871">said</a>:</p>
<blockquote>
<p>As for LLVM specifically, I am wary of our dependence on it... I am wary of being at the mercy of C++ and LLVM's priorities (esp. wrt. soundness, compile times).<br>
If features that a lot of users use can only be used on LLVM, then it means that any alternative backend is a second class citizen, and won't really be used.</p>
</blockquote>
<p>If we're not the ones pushing LLVM forward, then we <em>are</em> inherently at the mercy of their priorities. We can't have it both ways: either we're on the leading edge or we take what we get from the languages that are.<br>
And it isn't up to us to determine whether an alternative backend is "second-class" or not; that's up to the features of the backend. We should not choose to make <em>every</em> backend "second-class" so that none of them are.</p>



<a name="190456084"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190456084" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190456084">(Mar 12 2020 at 23:19)</a>:</h4>
<p><span class="user-mention silent" data-user-id="126931">centril</span> <a href="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190444341" title="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190444341">said</a>:</p>
<blockquote>
<p><span class="user-mention silent" data-user-id="116122">simulacrum</span> <a href="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190444187" title="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190444187">said</a>:</p>
<blockquote>
<p>Also, am I wrong, or is instruction_set not actually spec dependence on LLVM? i.e. the details on what it means are entirely "open" and not tied to LLVM specific details?</p>
</blockquote>
<p>Well if it is not a hint, then it compells other backends to expose a way to also achieve the behavior (unless it's an error on those backends)</p>
</blockquote>
<p>Either of those is acceptable. Either it works, or it gives an error saying it can't work. (If people want their code to work on that backend, they can either avoid that feature, use cfg, or fix the backend.</p>



<a name="190456139"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190456139" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190456139">(Mar 12 2020 at 23:20)</a>:</h4>
<p><span class="user-mention silent" data-user-id="116083">pnkfelix</span> <a href="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190444380" title="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190444380">said</a>:</p>
<blockquote>
<p>(And it is rather an ARM architecture thing. Maybe MIPS as well; need to double check the conversation there.)</p>
</blockquote>
<p>MIPS has <code>mips16</code> with very similar properties.</p>



<a name="190456250"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/190456250" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#190456250">(Mar 12 2020 at 23:22)</a>:</h4>
<p><span class="user-mention silent" data-user-id="126931">centril</span> <a href="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190444713" title="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190444713">said</a>:</p>
<blockquote>
<p>but highly LLVM-specific things would be worse</p>
</blockquote>
<p>For the record, this I agree with: we shouldn't unnecessarily tie our implementation to LLVM's if there's no good reason to do so. Witness the major effort we're going through to make our inline assembly syntax safer and simpler than LLVM's, and no longer subject to LLVM's ICE-producing limitations. We should specify features in a way that any backend could <em>theoretically</em> support. But we shouldn't refuse to specify a feature just because a backend doesn't support it.</p>



<a name="193413300"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/193413300" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> centril <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#193413300">(Apr 09 2020 at 07:00)</a>:</h4>
<p><span class="user-mention silent" data-user-id="239881">Josh Triplett</span> <a href="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190455569" title="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190455569">said</a>:</p>
<blockquote>
<p><span class="user-mention silent" data-user-id="116009">nikomatsakis</span> <a href="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190442540" title="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190442540">said</a>:</p>
<blockquote>
<p>Overall I guess I am worried about some kind of rule that says "everything must be easily supported by any 'ordinary' backend" -- it seems like it will limit us from taking full advantage of LLVM.</p>
</blockquote>
<p>Agreed completely. We are not a magical portability layer that must abstract over every possible difference between targets, and we certainly shouldn't force a lowest common denominator. We should take full advantage of a target when doing so provides value.</p>
</blockquote>
<p>I don't know what "magical" means here. However, in my view, a general-purpose high-level language like Rust is supposed to be a "portability layer" atop of the platform as that too provides value. It is reasonable to, and we do provide platform-specific functionality as well, but at a certain point, Rust is the wrong abstraction layer.</p>
<p><span class="user-mention silent" data-user-id="239881">Josh Triplett</span> <a href="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190455909" title="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190455909">said</a>:</p>
<blockquote>
<p><span class="user-mention silent" data-user-id="126931">centril</span> <a href="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190443645" title="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190443645">said</a>:</p>
<blockquote>
<p>I don't think it's bad personally; I don't think we should be making too many demands on a backend, to the point that making one becomes unreasonably hard, and it might also create problems for future backends.</p>
</blockquote>
<p>I feel precisely the opposite: we should hopefully, one day, be the force pushing our backends forward faster than C does, and providing access to interesting new functionality. At the very least, we should not be refusing to support existing functionality that our users need because of another backend that doesn't support it, let alone for a backend that we don't have yet.</p>
</blockquote>
<p>I think that depends on how widely applicable some addition requiring backend changes are wrt. "interesting new functionality" (usually this means more ad-hoc knobs in my experience). Making it too hard to implement a backend for Rust does in my view make us dependent on the limited set of backends we have. Also, I believe there will be a real effort to push us towards a Cranelift backend, which we had a compiler-team design meeting about recently.</p>
<p><span class="user-mention silent" data-user-id="239881">Josh Triplett</span> <a href="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190456023" title="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190456023">said</a>:</p>
<blockquote>
<p><span class="user-mention silent" data-user-id="126931">centril</span> <a href="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190443871" title="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190443871">said</a>:</p>
<blockquote>
<p>As for LLVM specifically, I am wary of our dependence on it... I am wary of being at the mercy of C++ and LLVM's priorities (esp. wrt. soundness, compile times).<br>
If features that a lot of users use can only be used on LLVM, then it means that any alternative backend is a second class citizen, and won't really be used.</p>
</blockquote>
<p>If we're not the ones pushing LLVM forward, then we <em>are</em> inherently at the mercy of their priorities. We can't have it both ways: either we're on the leading edge or we take what we get from the languages that are.<br>
And it isn't up to us to determine whether an alternative backend is "second-class" or not; that's up to the features of the backend. We should not choose to make <em>every</em> backend "second-class" so that none of them are.</p>
</blockquote>
<p>LLVM caters to C++, in my view, because that's what it was made for and because C++ has more users, not because C++ is supposedly pushing LLVM forward in terms of special knobs, which I personally believe most users don't use and don't know about. Also, many changes to LLVM have nothing to do with additional knobs that languages using LLVM expose. Rather, they include optimizations that get applied automatically and new forms of IR we can emit for better codegen.</p>
<p>I don't follow how it is not up to us to decide what minimal and maximal constraints we put on backends; that seems entirely up to us.</p>
<p>The argument that we would render every backend "second-class" resembles in my view "under X, everyone is equally poor", but second-class is a <em>relative</em> notion and is meaningless in the absolute.</p>
<p><span class="user-mention silent" data-user-id="239881">Josh Triplett</span> <a href="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190456084" title="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190456084">said</a>:</p>
<blockquote>
<p><span class="user-mention silent" data-user-id="126931">centril</span> <a href="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190444341" title="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190444341">said</a>:</p>
<blockquote>
<p><span class="user-mention silent" data-user-id="116122">simulacrum</span> <a href="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190444187" title="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190444187">said</a>:</p>
<blockquote>
<p>Also, am I wrong, or is instruction_set not actually spec dependence on LLVM? i.e. the details on what it means are entirely "open" and not tied to LLVM specific details?</p>
</blockquote>
<p>Well if it is not a hint, then it compells other backends to expose a way to also achieve the behavior (unless it's an error on those backends)</p>
</blockquote>
<p>Either of those is acceptable. Either it works, or it gives an error saying it can't work. (If people want their code to work on that backend, they can either avoid that feature, use cfg, or fix the backend.</p>
</blockquote>
<p>I'm not sure if you mean it that way, probably not, but "fix" suggests there's something wrong with the backend, but there might be perfectly good reasons why a backend does not want to support a certain feature, as it could be detrimental to other aspects of the backend. I think it's perfectly acceptable to weigh the detriment to portability in rendering certain backends "second class" vs. the benefits a certain feature comes with. How that will stack up in a particular case will depend on the specifics there.</p>
<p><span class="user-mention silent" data-user-id="239881">Josh Triplett</span> <a href="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190456250" title="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190456250">said</a>:</p>
<blockquote>
<p><span class="user-mention silent" data-user-id="126931">centril</span> <a href="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190444713" title="#narrow/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift/near/190444713">said</a>:</p>
<blockquote>
<p>but highly LLVM-specific things would be worse</p>
</blockquote>
<p>[...] We should specify features in a way that any backend could <em>theoretically</em> support. But we shouldn't refuse to specify a feature just because a backend doesn't support it.</p>
</blockquote>
<p>There are of course considerations beyond just the backend in accepting or rejecting a feature, but sticking just to the backend, I think "theoretically" is not enough; the constraints should not be set up in such a way that an implementation is only possible in principle but not in practice -- that would not be useful.</p>



<a name="193415690"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/LLVM%20capabilities%20vs%20cranelift/near/193415690" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/LLVM.20capabilities.20vs.20cranelift.html#193415690">(Apr 09 2020 at 07:35)</a>:</h4>
<p>But "it's an error" <em>was</em> deemed acceptable.</p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>